We could also support some #[try_from(<type>)] for types whose definition is a superset to the repr type.

@ModProg @JelteF yet another thing that I think of: we will definitely want to support this case in the future:

#[derive(TryFrom)]
enum Foo {
    #[try_from(u128)] // generates `impl TryFrom<u128> for Foo`
    Bar(u8),
}

While at the same time, in other situations we would like to have something like this:

#[derive(TryFrom)]
#[try_from(u128)] // generates `impl TryFrom<u128> for Foo`
#[repr(u8)]
enum Foo {
    Bar,
}

So, we need a way to differentiate a repr conversions from the ones of the inner types clearly.

And this question touches not only TryFrom, because we also will want to have something like this for Into:

#[derive(Into)] // generates `impl From<Foo> for u8`
#[repr(u8)]
enum Foo {
    Bar = 35,
}

And TryInto:

#[derive(TryInto)]
#[try_into(u8)] // generates `impl TryFrom<Foo> for u8`
#[repr(u128)] 
enum Foo {
    Bar = 35,
}

To disambiguate them clearly, I propose to use repr sub-attribute:

#[derive(Into, TryFrom)]
#[into(repr)] // generates `impl From<Foo> for u8`
#[try_from(repr)] // generates `impl TryFrom<u8> for Foo`
#[repr(u8)]
enum Foo1 {
    Bar,
}

#[derive(TryFrom, TryInto)]
#[try_from(repr(u128))] // generates `impl TryFrom<u128> for Foo`
#[try_into(repr(u8))] // generates `impl TryFrom<Foo> for u8`
#[repr(u16)]
enum Foo2 {
    Bar,
}

Does it make sense?

@tyranron, looks sensible. I'll implement support for the repr syntax for now, and will error on it not specified.

@tyranron how would you expect repr(<types>) to work?

impl TryFrom<$type> for $enum {
    fn try_from(value: $type) -> Result<Self> {
        let value: $actual_repr = value.try_into().map_err(|e| TryFromError::message(e.to_string())?;
        match value {
            $actual_implementation
        }
    }
}

@ModProg as a regular forwarding implementation, like you've pointed, yes. But as I've mentioned before, let's not making it as a part of this PR. Better implement as a separate one after merging this.

@JelteF yes, I was waiting for #298 to land. Give me a moment.

@JelteF oh, and please, change the required CI jobs in project settings to reflect MSRV 1.65.0 -> MSRV 1.72.0 migration. Otherwise, CI won't pass. Thanks!